Situation : ubuntu installé sur un HDD, et vous n'avez pas envie de réinstaller toute la configuration !
Le principe est le suivant :
$ sudo mkdir /mnt/ssd $ sudo mount /dev/sda1 /mnt/ssd/
1. Monter l'ensemble des arborescences des répertoires "/proc","/sys" et "/dev" à la racine de la nouvelle partition Ubuntu:
$ sudo mount --bind /proc /mnt/ssd/proc $ sudo mount --bind /sys /mnt/ssd/sys $ sudo mount --bind /dev /mnt/ssd/dev
l'argument "–bind" fait en sorte de monter toute l'arborescence.
2. Exécuter à présent un chroot sur la racine de la nouvelle partition:
$ sudo chroot /mnt/ssd
Ceci étant fait, il faut savoir qu'à présent, c'est comme si nous avions booté sur cette partition.
3. Enfin, Réinstallation de GRUB
$ sudo grub-install /dev/sda #### ou sudo grub-install si boot EFI
Une dernière petite chose à faire avant d'en avoir terminé, mettre à jour la configuration de GRUB par:
$ sudo update-grub
En effet, comme les UUID des partitions ont changé, nous avons informé fstab, mais pas les fichiers de config GRUB Vous pouvez à présent quitter le chroot par
$ exit
Voilà, c'est fini!
Penser à modifier le Bios LEGACY pour lui dire de booter prioritairement sur le NVME au lieu du disque dur. En effet le boot peut se faire directement sur le SSD 1. Redémarrer en Bootant sur le SSD (en désactivant l'ancien disque si boot LEGACY et si pas de partition de swap et si pas de partition home ou de données).
sudo grub-install /dev/sda sudo update-grub
2. Rebooter une dernière fois le PC. Voilà, c'est fini !
La solution retenue est de continuer à booter avec la partition EFI du disque dur. Cependant, il semble préférable que la structure de boot soit dans le même disque que le logiciel. Pour résoudre ce problème, boot-repair est utilisable ainsi que la ligne de commande.
sed -i '/boot\/efi/d' /etc/fstab && echo UUID=$(lsblk -o UUID,NAME,LABEL | grep FATSSD | cut -c-9) /boot/efi vfat umask=0077 0 1| sudo tee -a /etc/fstab
sudo umount -v /boot/efi && sudo mount -av
sudo grub-install && sudo update-grub
sudo efibootmgr --create --disk /dev/$(lsblk -l -o NAME,LABEL|grep FATSSD |cut -c-3) --part 1 --label "ubuntu" --loader "\EFI\ubuntu\shimx64.efi" ### Si SSD standard sudo efibootmgr --create --disk /dev/$(lsblk -l -o NAME,LABEL|grep FATSSD |cut -c-7) --part 1 --label "ubuntu" --loader "\EFI\ubuntu\shimx64.efi" ### Si NVME
A faire avant d'avoir oublié que le disque dur est resté la référence de boot. Voici c'est terminé.
Lorsque la partition logicielle de ubuntu dans le disque dur est plus volumineuse que le futur SSD, la situation n'est pas bloquée.
Il faut d'abord identifier la cause. Il y a toutes les chances que les données personnelles soient stockées dans la partition logicielle. Il n'y a pas d'avantages particuliers à stocker les données personnelles dans le SSD.
La proposition est alors de conserver les données personnelles dans le disque dur et de dupliquer le logiciel. Le logiciel du disque dur pourra être supprimé ultérieurement lorsque le manque de place sur le disque dur sera détecté.
Le transfert du logiciel ne se fera pas par clonezilla mais en lignes de commandes afin de pouvoir sélectionner.
Avec le ubuntu fonctionnant, installer l'application gparted afin de pouvoir formater le SSD. Créer:
sudo -i
udisksctl unmount -b /dev/disk/by-label/NewUbuntu ## On ne sait jamais udisksctl mount -b /dev/disk/by-label/NewUbuntu
time rsync -ax --delete-before --stats --exclude '/home' / /media/$USER/NewUbuntu
for Me in $(ls -1 /home) ; do mkdir -pv /media/$USER/NewUbuntu/home/$Me echo le transfert de $Me rsync -ax --stats --progress /home/$Me/{.[^.]*,snap} /media/$USER/NewUbuntu/home/$Me ln -s /media/data/home/$Me/Bureau /media/$USER/NewUbuntu/home/$Me ln -s /media/data/home/$Me/Documents /media/$USER/NewUbuntu/home/$Me ln -s /media/data/home/$Me/Images /media/$USER/NewUbuntu/home/$Me ln -s /media/data/home/$Me/Musique /media/$USER/NewUbuntu/home/$Me ln -s /media/data/home/$Me/Téléchargements /media/$USER/NewUbuntu/home/$Me ln -s /media/data/home/$Me/Vidéos /media/$USER/NewUbuntu/home/$Me chown -R $Me:$Me /media/$USER/NewUbuntu/home/$Me; done
UUIDgood=$(echo $(lsblk -fe7 | grep "NewUbuntu")| cut -d" " -f5) && echo $UUIDgood UUIDold=$(grep ' \/ ' /etc/fstab | grep UUID | cut -c6-41) && echo $UUIDold sed -i "s/$UUIDold/#$UUIDold/" /media/$USER/NewUbuntu/etc/fstab echo UUID=$UUIDgood / ext4 errors=remount-ro 0 1 | tee -a /media/$USER/NewUbuntu/etc/fstab echo UUID=$UUIDold /media/data ext4 defaults 0 2 | tee -a /media/$USER/NewUbuntu/etc/fstab mkdir /media/$USER/NewUbuntu/media/data egrep " / |data" /media/$USER/NewUbuntu/etc/fstab
sed -i '/boot\/efi/d' /media/$USER/NewUbuntu/etc/fstab echo UUID=$(lsblk -o UUID,NAME,LABEL | grep FATSSD | cut -c-9) /boot/efi vfat umask=0077 0 1| tee -a /media/$USER/NewUbuntu/etc/fstab sed -i "s/$UUIDold/$UUIDgood/" /media/$USER/$LABEL/boot/refind_linux.conf
Il existe 2 possibilités pour installer le bon grub dans cette nouvelle partition.
mount -t proc /proc /media/$USER/NewUbuntu/proc && mount -t sysfs /sys /media/$USER/NewUbuntu/sys mount --bind /dev /media/$USER/NewUbuntu/dev && mount --bind /run /media/$USER/NewUbuntu/run mount --bind /sys /media/$USER/NewUbuntu/sys && modprobe efivars chroot /media/$USER/NewUbuntu
mount -v /dev/disk/by-label/FATSSD /boot/efi
grub-install $(blkid | grep 'FATSSD' | head -1 | cut -c1-8 ) update-grub
umount -v /boot/efi exit
DSK=$(echo /dev/$(lsblk -o NAME,Label | grep -B 1 FATSSD | head -1)) && echo $DSK if [[ $(bootctl) =~ "Secure Boot: disabled" ]]; then efibootmgr --create --disk $DSK --part 1 --label ubuntu --loader "\EFI\ubuntu\grubx64.efi"; else efibootmgr --create --disk $DSK --part 1 --label ubuntu --loader "\EFI\ubuntu\shimx64.efi"; fi
umount -v /media/$USER/NewUbuntu/{run,dev,sys,proc} && umount /media/$USER/NewUbuntu/sys umount -v /media/$USER/NewUbuntu exit
Cette méthode peut s'appliquer:
Réalisation
Erreur possible
Lors d'un boot EFI, les anciennes versions, imposent le N° de partition qui peut avoir changé. Donc si plantage, lancer boot repair et réparer le ubuntu du SSD afin qu'il réinstalle la structure EFI avec un bon numéro.
